In the session initiation protocol (SIP for short) system, call forwarding (communication diversion) is a common and practical service, which makes the call server of the called party forward the call to the user equipment of the call-forwarded party, when the called party enabling the call forwarding service is in an unreachable or busy or other states in the call process, thus improving the flexible configurability of the call, wherein the user equipment of the call-forwarded party is set in advance by the called party.
The call forwarding includes the following several service types: call forwarding busy (CFB), call forwarding no reply (CFNR), call forwarding unconditional (CFU), call forwarding no reachable (CFNRc), call forwarding no login (CFNL) and communication diversion (CD). The service allows the user to forward all its incoming call to another telephone number which is set in advance, or a voice mail of the user. When activating the call forwarding unconditional (CFU), the system can also provide a permitted call. The call forwarding also includes a special case of a plurality of forwarding call, that is, the user A calls the user B, the user B uses the call forwarding service, the call is forwarded to the user C, the user C also uses the call forwarding service, and the call is further forwarded to the user D.
It is introduced briefly hereinafter that the call server sends a call request message to the call-forwarded party through the IMS network in the call forwarding service (defined as INVITE message in the protocol, the message is based on the SIP protocol). When the call forwarding occurs, the call server receives the INVITE message including the ticket from the calling party, and forwards the message to the call-forwarded party, and adds a CAUSE parameter (the CAUSE parameter represents that the call forwarding service is used and the type used therein), and for the specific usage and instruction, please refer to RFC4458 and TS24.604 v9.2.0.
For example, the calling party is user 1, which is identified as user1_public1@home1.net, and the called party is user 2, which is identified as user2_public1@home1.net. The user 2 enables the call forwarding unconditional service, and the target of the call forwarding is set as user 3, which is identified as user-3@example.com. The call server to which the user 2 belongs forwards to the user 3 a call from the user 1 to the user 2, and includes the state parameter “CAUSE=302” in the INVITE message sent to the user 1 The parameter of which the value is 302 represents that the call type is call forwarding unconditional.
The key management server (KMS for short) is used in the IMS media plane security in the 3GPP TS33.328. FIG. 1 is a framework diagram of the IMS media security solution based on the KMS in the related art, wherein, the user A (UE-A) and the user B (UE-B) are the sending party and receiving party of the media message; the key management server (KMS), as a reliable third party, realizes the management and distribution function of the key; proxy-call session control function (P-CSCF) and service-call session control function (S-CSCF) are network elements in the IMS network; for the function introduction of other network elements, please refer to the relevant documents.
FIG. 2 is a diagram of a call process based on the KMS in the prior art. In the process of establishing the call of the calling party and the called party, the calling party sends a request message (REQUEST-INT) to the KMS to request the relevant key and ticket. The KMS returns a response message (REQUEST-RESP) to the calling party, where the response message includes the ticket requested by the calling party, wherein the ticket is based on the public user identifier of the called party, and the ticket includes the encrypted relevant key, calling party identifier and called party identifier. The calling party sends the ticket to the called party through the transmission message (TRANSFER-INIT). Since the called party is unable to decrypt the ticket, the ticket is sent to the KMS through the resolution message (RESOLVE-INIT), then the KMS decrypts the ticket, and after decrying the ticket, returns the relevant key therein to the called party. The KMS acquires the called party identifier through the ticket, and compares whether the called party identifier in the ticket and a reply party identifier which sends the TRANSFER-INIT message are the same; if the two identifiers are the same, then it will be judged that the reply party is the legal called party.
In the common call process, the reply party which sends the RESOLVE-INIT to the KMS is the called party in the call, which can pass through the authentication on the called user identity by the KMS successfully; in the branching call case, one calling party calls a plurality of called parties at the same time, however, a plurality of called parties are all corresponding to one same public user identifier, so a plurality of reply terminals can also pass through the user identity authentication; while in the call forwarding case, the call-forwarded party can be set arbitrarily at any time by the user using the service, and finally the reply party may have different public user identifier from the original called party respectively. In the situation, the above-mentioned authentication method for the public user identifier based on the called party will be no longer applicable, which causes that it is unable to authenticate the identity of the reply party, thus causing the call failed. So the new solution is needed to realize the secure call forwarding.